Different methods for handling audio of a conference are known in the art. Typically, the same architecture for handling audio is used regardless of whether the conference is “small” or “large.” A “large” conference may be considered as having ten or more conferees, for example. In a conference, a Multipoint Control Unit (MCU) controls the audio and/or audio/video. The MCU is typically located in a node of a network or in a terminal, such as an “endpoint” associated with a user who participates in the audio or audio/video conference. The MCU receives several channels from access ports, processes audio and visual signals according to certain criteria, and distributes the processed signals to a set of connected channels. An example of an MCU includes the MGC-100, which is available from Polycom Inc. It should be noted that an MCU may also be referred to as an Audio Bridge when only used for an audio conference, and therefore in the present disclosure, the term “MCU” may also be used to represent an Audio Bridge.
When conducting a “large” conference, each conferee is typically connected to a common audio port in the MCU. The audio ports include a decoder, audio signal analyzer (to analyze for example signal energy, DTMF (Dual Tone Multi-Frequency) signaling, voice activation commands, etc.), a mixer, an encoder, and a controller. More information about common audio ports in a multipoint control unit (MCU) can be found in U.S. Patent Application Publication Nos. U.S. 20020123895 and U.S. 20020188731, which are both incorporated herein by reference in their entireties.
Conducting a “large” conference requires a large number of audio resources, increases the cost of the MCU, and reduces the number of conferences that can be simultaneously controlled by an MCU. Furthermore, a large common interface (a bus, for example) is typically required to carry the open audio between the different audio ports associated with the same conference. In some cases, a larger common interface increases the delay between talking and listening, because the time interval between two sequential transactions over the bus increases with the size of the bus. In addition, a large number of inputs and outputs modules associated with the same conference place a heavy load on the controller of the conference.
Another prior art method for handling the audio of a “large” conference delivers an audio port to each one of the conferees that belongs to a particular group of conferees (a panel, for example). The rest of the conferees (e.g., the audience) receive a multicast or broadcast of the mixed audio of the panel. This method reduces the load on the controller and required resources. However, a conferee in the audience is unable to contribute to the conference. For example, the audience member is unable to take any active part in the conference or to change the conferee's current state as an audience member in the conference. In addition, the audience member is unable to speak, to vote on a topic being discussed during the conference, etc.
Current techniques for processing the audio of a “large” conference are thus not ideal, and a need exists in the art for a system and method for better controlling the audio of a “large” conference.